System architecture with secure data exchange

ABSTRACT

In an embodiment, a system comprises: a first bus; a second bus; a first peripheral coupled to the first bus and the second bus, the first peripheral configured to receive a command from the first bus and to generate data in response to the first command; and a second peripheral coupled to the first bus and the second bus, the second peripheral configured to initiate transfer of the generated data from the first peripheral to the second peripheral over the second bus such that access to the generated data through the first bus is prevented.

TECHNICAL FIELD

This disclosure relates to system architectures.

BACKGROUND

A system on chip (SoC) used in secure applications may be configured toexchange sensitive data within the SoC in a secure manner. For example,an application using a cryptographic algorithm may exchangecryptographic keys between peripherals in the SoC. If the cypher keytransfer occurs on a software accessible system bus the data becomesvulnerable to third party attacks which may result in exposure of thecypher keys.

SUMMARY

In an embodiment, a system comprises: a first bus; a second bus; a firstperipheral coupled to the first bus and the second bus, the firstperipheral configured to receive a command from the first bus and togenerate data in response to the first command; and a second peripheralcoupled to the first bus and the second bus, the second peripheralconfigured to initiate transfer of the generated data from the firstperipheral to the second peripheral over the second bus such that accessto the generated data through the first bus is prevented.

In an embodiment, a method comprises: sending, by a master or peripheralin a system having a first bus and a second bus, a first command to afirst peripheral coupled to the first bus and the second bus, the secondbus configured to prevent access through the first bus to datatransferred on the second bus; receiving, by the first peripheral, thefirst command from the first bus; generating, by the first peripheral,data in response to the first command; and initiating, by a secondperipheral coupled to the second bus, a transfer of the data on thesecond bus from the first peripheral to the second peripheral.

In an embodiment, a device comprises: an interface configured to coupleto a first bus; a second bus; and a first peripheral coupled to theinterface and the second bus, the first peripheral configured to receivea command over the interface, to generate data in response to thecommand and to transfer the data to a second peripheral over the secondbus such that access to the generated data through the first bus isprevented.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a conceptual block diagram of an example system with securedata exchange, in accordance with an embodiment.

FIGS. 2A-2C show three sets of example waveforms illustrating threeexample secure data transfer protocols on a secure bus, in accordancewith various embodiments.

FIG. 3 is a flow diagram of an example process for secure data exchangeon a secure data bus, in accordance with an embodiment.

FIG. 4 is a conceptual block diagram of an example peripheral configuredto perform secure data exchange.

DETAILED DESCRIPTION

In an embodiment, a cryptographic algorithm is implemented, such as, forexample, Advanced Encryption Standard (AES). In one embodiment, however,the disclosed system architecture and protocol is applicable to anyapplication that would benefit from on-chip secure data transfer.Moreover, one embodiment includes a secure bus for sensitive datatransfer using a secure data transfer protocol to avoid attack duringdata transfer. The secure bus cannot be accessed by software configuredto communicate over or have access to the system bus. Peripherals thatneed to transfer sensitive data with each other are coupled to thesecure bus and exchange the sensitive data on the secure bus (ratherthan the system bus) using the secure data transfer protocol. In anembodiment, the data transfer includes integrity packets for checkingfor data corruption during the data transfer on the secure bus. Theintegrity packets can be transferred with the data using a number offormats, including, but not limited to: interleaved integrity packets,non-interleaved integrity packets and randomly interleaved integritypackets.

As used herein, the terms “block,” “module” or “processing block” referto one or more circuits that work together to perform one or moreoperations. A “block,” “module” or “processing block” may also executesoftware or firmware to perform the set of operations depending on theapplication.

Example System

FIG. 1 is a conceptual block diagram of an example system 100, inaccordance with an embodiment. System 100 can be included in anintegrated circuit chip, such as a microcontroller unit or SoC. System100 includes central processing unit 101 (CPU), direct memory access(DMA)/peripheral data controller (PDC) 102, memory 103, peripheral busbridge 104, double data rate (DDR) controller 105 and display controller106, each of which is coupled to bus 111. System bus 105 can be, forexample, an advanced microcontroller bus architecture (AMBA)high-performance bus (AHB) or bus matrix (AXI). Additionally, peripheralbus bridge 104 couples bus 111 to peripheral bus 112. Peripheral bus 112can be, for example, an AMBA peripheral bus (APB) bus matrix. Bus 111and peripheral bus 112 are also referred to individually or collectivelyas a “system bus.”

Several peripherals or processing blocks are coupled to peripheral bus112, including AES block 108, one-time programmable (OTP) controller 109and random number generator (RNG) block 110. In practice,microcontroller system 100 can include more or fewer components orsubsystems than is shown in FIG. 1.

Referring to the system bus components, if DMA/PDC controller 102 is aDMA controller, DMA controller 102 transfers data between memories andperipherals with minimal intervention by CPU 101. While CPU 101 spendstime in sleep modes or performs other tasks, DMA/PDC controller 102offloads CPU 101 bus transfer tasks by copying data from one area toanother. A complete DMA read and write operation between memories and/orperipherals is called a DMA transaction. A transaction is performed byDMA/PDC controller 102 in data blocks and the size of the transaction(number of bytes to transfer) is selectable from software and controlledby the block size and repeat counter settings.

If DMA/PDC controller 102 is a PDC controller, PDC controller 102transfers data between on-chip serial peripherals and on and/or off-chipmemories. Using the PDC removes processor overhead by reducing itsintervention during the transfer. This significantly reduces the numberof clock cycles for a data transfer, which improves microcontrollersystem performance. To launch a transfer, the peripheral triggers itsassociated PDC channels by using handshake signals. When the programmeddata is transferred, an end of transfer interrupt indicating the end ofthe data transfer is generated by the peripheral itself.

In an embodiment, DDR controller 105 is used to drive DDR memory (e.g.,synchronous dynamic random access memory (SDRAM)), where data istransferred on both rising and falling edges of the system's memoryclock signal. Display controller 106 can be, for example a liquidcrystal display (LCD) controller for activating a segment of an LCDdisplay.

Referring to the peripherals on peripheral bus 112, AES block 108performs AES encryption/decryption processes, OTP matrix controller 109permanently stores a cypher key. RNG 110 generates a random number usedto generate the cypher key. AES is a symmetric block cipher. Each cipherencrypts and decrypts data in blocks (e.g., 128 bits) usingcryptographic keys (e.g., 128, 192 or 256 bits), respectively. Symmetricor secret-key ciphers use the same key for encrypting and decrypting, soboth the sender and the receiver know and use the same secret key.Depending on key length, there are several processing steps that includesubstitution, transposition and mixing of an input plaintext andtransform it into a final output of cipher text.

In an example embodiment, a cryptographic application running on system100 uses RNG 110 to generate a random number that can be used togenerate a cypher key for an AES algorithm implemented by AES block 108.Secure bus 113 is coupled to RNG 110, OTP controller 109 and AES block108. Secure bus 113 is configured to prevent access to data transferredon secure bus 113. For example, malicious commands executed byapplication software that are transferred over system bus 105 cannotaccess data transferred on secure bus 113. Secure bus 113 can thereforebe used to defend against, for example, a buffer overflow attack.

Although in this example all three blocks share peripheral bus 112, thedisclosed embodiments are not limited to blocks coupled to the same bus.In an embodiment, secure bus 113 includes a data bus 113 a, a commandbus 113 b and an error checking bus 113 c. The secure bus 113 can bebidirectional. In an embodiment, data bus 113 a includes a write databus and a read data bus. In an embodiment, secure bus 113 can managesynchronous transmissions or asynchronous transmissions depending on theapplication. Synchronous transmissions are synchronized by an externalclock while asynchronous transmissions are synchronized by signals alongsecure bus 113. Asynchronous transmissions use less hardware and aresuited for applications where data is transferred at irregularintervals. Synchronous transmission has lower overhead and greater datathroughput.

When application software initializes system 100, the applicationsoftware is configured, when executed by CPU 101, to cause CPU 101 tosend a first command on peripheral bus 112 to RNG block 110 to generatea random number for a cypher key. RNG 110 implements a true randomnumber generator in software and/or hardware. The application software,when executed by CPU 101, causes CPU 101 to send a second command onperipheral bus 112 to AES block 108 to initiate transfer of the randomnumber from RNG block 110 to AES block 108 using secure bus 113. AESblock 108 generates the key using the random number and then stores thekey in AES key register 114a (R1). The transfer is aperipheral-to-peripheral (P2P) transfer from RNG block 110 to AES block108 over secure bus 113 without any temporary storage of the cypher keyin, for example, system memory. Thus, the transfer of the cypher keyoccurs outside the application's control on secure bus 113.

In an embodiment, OTP controller 109 may store the cypher keyspermanently in a secure register or secure memory, such as OTP memory(e.g., EPROM). After the cypher key has been stored in the first AES keyregister 114a, a third command can be sent to OTP controller 109 onperipheral bus 112 to transfer the cypher key from the secured memory orregister to a second AES key register 114b (R2) using secure bus 113.

In general, any number of peripherals can be coupled to secure bus 113and each peripheral coupled to secure bus 113 can transfer to andreceive data from one or more other peripherals coupled to secure bus113. In an embodiment, two or more peripherals can be coupled to securebus 113 but not to system bus 105 or peripheral bus 112.

FIGS. 2A-2C are three sets of waveforms illustrating a secure datatransfer protocol on secure bus 113, in accordance with an embodiment.During the cypher key transfer on secure bus 113 a third party couldforce secure bus 113 to a value (e.g., all “1s”or “0s”) and thus breakthe application security that enforces the cipher key. To address thisissue, an embodiment uses integrity data to prevent such attack. Forexample, for every packet of data transferred (e.g., a byte of data) onsecure bus 113 a corresponding integrity data packet can be generated.Corruption detection block 116 coupled to secure bus 113 receives thecypher key data from secure bus 113 and detects if the data packet hasbeen corrupted while being transferred on secure bus 113 using theintegrity data packet. In an embodiment, the integrity data packetincludes a cyclic redundancy check (CRC) code (e.g., a byte), but anintegrity data packet can be generated using other codes and methods.

In an embodiment, corruption detection block 116 can be coupled to thesystem bus (e.g., peripheral bus 112) so that when corruption detectionblock 116 detects data corruption in the cypher key data on secure bus113 it can inform the application of the corruption so that theapplication can initiate security measures. In an embodiment, corruptiondetection block 116 can be included in a peripheral (e.g., included inAES block 108).

Referring to FIG. 2A, a first set of waveforms 200 illustrate how keybytes are interleaved with their corresponding integrity packet. In FIG.2A, Key n is the “n”-th byte of a 128-bit AES key and Integrity Packet“n” is its corresponding integrity check byte. Referring to FIG. 2B, asecond set of waveforms 201 illustrate how the integrity packets aretransferred after their corresponding key bytes are transferred.Referring to FIG. 2C, a third set of waveforms 202 illustrate how theintegrity packets are randomly interleaved between their correspondingkey bytes. In an embodiment, the data sequence order is randomlyselected by a master (e.g., CPU 102) each time a new key transfer isrequested. The random interleaving of integrity packets with cypher keydata prevents attacks on secure bus 113 during data transfer.

Generally, integrity packets can be transferred with their correspondingcypher key data in multiple ways, including but not limited to:interleaving integrity data with cypher key data, interleaving integritydata randomly with cypher key data, transferring integrity data beforeall corresponding cypher key data is transferred and transferringintegrity data after all corresponding cypher key data is transferred.Integrity data can be CRC codes or any other error detection and/orcorrection code. In an embodiment, in addition to or in lieu of usingintegrity data, addresses and/or data can be scrambled dynamicallybefore being transferred on secure bus 113.

Example Process

FIG. 3 is a flow diagram of an example process for secure data exchangeon a secure data bus, in accordance with an embodiment. Process 300 canbe implemented by, for example, system 100 described in reference toFIG. 1.

In some implementations, process 300 can begin by receiving, by aperipheral, a data transfer request on a system bus (302). A system buscan include one or more buses including a peripheral bus, such asperipheral bus 112 shown in FIG. 1. The request can be sent by, forexample, a master (e.g., a CPU) or another peripheral. The request cancause the peripheral to generate data to be shared with, for example,another peripheral.

Process 300 can continue by determining that the transfer request is forsensitive data in response to the request (304). Using the previousexample, if sensitive data is to be transferred, RNG block 110 cangenerate a random number for generating a cypher key.

Process 300 can continue by generating integrity data (306). Theintegrity data (e.g., a CRC code) can be interleaved with key data,appended to the beginning or the end of the key data or randomlyinterleaved with key data. In an embodiment, addresses or data can bescrambled before being transferred on secure bus 113. For example, amaster or peripheral can issue a secure bus command to initiate a datatransfer over secure bus 113. Using the previous example, a command issent to OTP controller 109 to request a data transfer of the randomnumber from secure memory or a secure register to AES block 108 oversecure bus 113.

Process 300 can continue by transferring data packets with correspondingintegrity data on secure bus 113 in response to a secure bus commandgenerated by peripheral (308). For example, the data can be transferredin data packets on secure bus 113 along with corresponding integritydata packets to ensure the integrity of the data transferred.

Referring to FIG. 2A, a secure bus clock can be used for synchronoustransmission of data packets and integrity data packets on secure bus113. A first peripheral can issue a first secure bus command to a secondperipheral to transfer a data packet (e.g., cypher key data). The firstsecure bus command is followed by a second secure bus command totransfer an integrity data packet corresponding to the data packet. Atthe second peripheral the first and second secure bus commands are usedto initiate transfer of the data packet, followed by the transfer of thecorresponding integrity data packet on secure bus 113. The transfer canterminate when the requested data packets and integrity data packetshave been transferred to the first peripheral.

Referring to FIG. 2B, a first peripheral can issue a first set of securebus commands to transfer data packets. After issuing the first set ofsecure bus commands to transfer data packets, the first peripheral canissue a second set of secure bus commands to transfer integrity datapackets corresponding to the data packets. At the second peripheral thefirst set of secure bus commands are used to initiate transfer of thedata packets and the second set of secure bus commands are used toinitiate transfer of the integrity data packets on secure bus 113. Thetransfer can terminate when the requested data packets and integritydata packets have been transferred to the first peripheral.

Referring to FIG. 2C, a first peripheral can issue a first secure buscommand to a second peripheral to get a first data packet. The firstsecure bus command is followed by a second secure bus command totransfer either a second data packet or a first integrity data packetcorresponding to the first data packet. Whether or not the second datapacket or the first integrity data packet is transferred is randomlydetermined by, for example, the first peripheral or a master. Thisrandom interleaving continues until secure bus commands are sent for allthe requested data packets and corresponding integrity data packets. Atthe second peripheral, transfer is initiated for data packets andintegrity data packets in response to the randomly interleaved transferrequests from the first peripheral or master. The data transfer canterminate when the requested data packets and corresponding integritydata packets have been transferred to the first peripheral.

FIG. 4 is a conceptual block diagram of an example peripheral 400configured to perform secure data exchange. Some example peripherals areAES 108, OTP controller 109 and RNG block 110. In an embodiment,peripheral 400 can include system bus interface 401, secure businterface 402, processing circuitry/logic 403 and memory 404. In anembodiment, system bus interface 401 includes circuitry for interfacingwith a system bus (e.g., APB matrix 112), including but not limited to:address decoders, registers, buffers, signal conditioning circuitry andthe like. Secure bus interface 402 includes circuitry for interfacingwith a system bus (e.g., APB matrix 112), including but not limited to:address decoders, registers, buffers, signal conditioning circuitry andthe like. In an embodiment, system bus interface 401 and/or secure businterface 402 can include a bus controller configured to manageinput/output of address, data and control signals to and from the systembus and secure bus. A bus controller in secure bus interface 402 can beconfigured to generate data packets and integrity data packets andgenerate the secure bus commands shown in FIGS. 2A-2C. Processingcircuitry/logic 403 can include circuitry for performing one or moreapplications and store data generated or used by those application(s) inmemory 404.

While this document contains many specific implementation details, theseshould not be construed as limitations on the scope of what may beclaimed but rather as descriptions of features that may be specific toparticular embodiments. Certain features that are described in thisspecification in the context of separate embodiments can also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment canalso be implemented in multiple embodiments separately or in anysuitable sub combination. Moreover, although features may be describedabove as acting in certain combinations and even initially claimed assuch, one or more features from a claimed combination can, in somecases, be excised from the combination, and the claimed combination maybe directed to a sub combination or variation of a sub combination.

What is claimed is:
 1. A system comprising: a first bus; a second bus; afirst peripheral coupled to the first bus and the second bus, the firstperipheral configured to receive a command from the first bus and togenerate data in response to the first command; and a second peripheralcoupled to the first bus and the second bus, the second peripheralconfigured to initiate transfer of the generated data from the firstperipheral to the second peripheral over the second bus such that accessto the generated data through the first bus is prevented.
 2. The systemof claim 1, wherein the first peripheral is configured to: generateintegrity data corresponding to the data; and transfer the data with theintegrity data to the second peripheral over the second bus.
 3. Thesystem of claim 2, further comprising: a corruption detection modulecoupled to the second bus and configured to detect data corruption usingthe integrity data.
 4. The system of claim 2, wherein the firstperipheral is further configured to: generate data packets from thegenerated data; generate integrity data packets corresponding to thedata packets from the generated integrity data; and transfer the datapackets, interleaved with the corresponding integrity data packets, overthe second bus.
 5. The system of claim 2, wherein the first peripheralis further configured to: generate data packets from the generated data;generate integrity data packets corresponding to the generated datapackets from the generated integrity data; transfer the data packetsover the second bus; and following the transfer of the data packets overthe second bus, transfer the corresponding integrity data packets overthe second bus.
 6. The system of claim 2, wherein the first peripheralis further configured to: generate data packets from the generated data;generate integrity packets corresponding to the generated data packetsfrom the generated integrity data; and transfer the data packets,randomly interleaved with the corresponding integrity data units, overthe second bus.
 7. The system of claim 1, wherein at least one of thefirst and second peripheral is configured to perform cryptographicoperations.
 8. The system of claim 1, wherein the integrity dataincludes a cyclic redundancy check (CRC) code.
 9. The system of claim 1,wherein the secure bus is a synchronous bus.
 10. A method comprising:sending, by a master or peripheral in a system having a first bus and asecond bus, a first command to a first peripheral coupled to the firstbus and the second bus, the second bus configured to prevent accessthrough the first bus to data transferred on the second bus; receiving,by the first peripheral, the first command from the first bus;generating, by the first peripheral, data in response to the firstcommand; and initiating, by a second peripheral coupled to the secondbus, a transfer of the data on the second bus from the first peripheralto the second peripheral.
 11. The method of claim 10, furthercomprising: generating, by the first peripheral, integrity datacorresponding to the data; and transferring, by the first peripheral,the data with the integrity data to the second peripheral over thesecond bus.
 12. The method of claim 10, further comprising: detecting,by a corruption detection module coupled to the second bus, corrupteddata using the integrity data.
 13. The method of claim 11, furthercomprising: generating, by the first peripheral, data packets from thegenerated data; generating, by the first peripheral, integrity datapackets corresponding to the data packets from the generated integritydata; and transferring, by the first peripheral, the data packets,interleaved with the corresponding integrity data packets, over thesecond bus.
 14. The method of claim 11, further comprising: generating,by the first peripheral, data packets from the generated data;generating, by the first peripheral, integrity data packetscorresponding to the generated data packets from the generated integritydata; transferring, by the first peripheral, the data packets over thesecond bus; and following the transfer of the data packets over thesecond bus, transferring the corresponding integrity data packets overthe second bus.
 15. The method of claim 11, further comprising:generating, by the first peripheral, data packets from the generateddata; generating, by the first peripheral, integrity packetscorresponding to the generated data packets from the generated integritydata; and transferring the data packets, randomly interleaved with thecorresponding integrity data units, over the second bus.
 16. The methodof claim 10, wherein at least one of the first and second peripheral isconfigured to perform cryptographic operations.
 17. The method of claim10, wherein the integrity data includes a cyclic redundancy check (CRC)code.
 18. The method of claim 10, wherein the second bus is asynchronous bus.
 19. A device comprising: an interface configured tocouple to a first bus; a second bus; and a first peripheral coupled tothe interface and the second bus, the first peripheral configured toreceive a command over the interface, to generate data in response tothe command and to transfer the data to a second peripheral over thesecond bus such that access to the generated data through the first busis prevented.
 20. The device of claim 19, wherein the second peripheralis further configured to: generate integrity data; and initiate transferof the data from the first peripheral to the second peripheral over thesecond bus with the integrity data.